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Single Nickname for an Area Border RBridge in 
Multilevel Transparent Interconnection of Lots of 
Links (TRILL) 


Abstract 


A major issue in multilevel TRILL is how to manage RBridge nicknames. In this document, area 
border RBridges use a single nickname in both Level 1 and Level 2. RBridges in Level 2 must 
obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9183. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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Authors' Addresses 


1. Introduction 


February 2022 


TRILL (Transparent Interconnection of Lots of Links) [RFC6325] [RFC7780] multilevel techniques 
are designed to improve TRILL scalability issues. 
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"Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)" [RFC8243] is 
an educational document to explain multilevel TRILL and list possible concerns. It does not 
specify a protocol. As described in [RFC8243], there have been two proposed approaches. One 
approach, which is referred to as the "unique nickname" approach, gives unique nicknames to all 
the TRILL switches in the multilevel campus either by having the Level 1/Level 2 border TRILL 
switches advertise which nicknames are not available for assignment in the area or by 
partitioning the 16-bit nickname into an "area" field and a "nickname inside the area" field. 
[RFC8397] is the Standards Track document specifying a "unique nickname" flavor of TRILL 
multilevel. The other approach, which is referred to in [RFC8243] as the "aggregated nickname" 
approach, involves assigning nicknames to the areas, and allowing nicknames to be reused 
inside different areas, by having the border TRILL switches rewrite the nickname fields when 
entering or leaving an area. [RFC8243] makes the case that, while unique nickname multilevel 
solutions are simpler, aggregated nickname solutions scale better. 


The approach specified in this Standards Track document is somewhat similar to the "aggregated 
nickname" approach in [RFC8243] but witha very important difference. In this document, the 
nickname of an area border RBridge is used in both Level 1 (L1) and Level 2 (L2). No additional 
nicknames are assigned to represent L1 areas as such. Instead, multiple border RBridges are 
allowed and each L1 area is denoted by the set of all nicknames of those border RBridges of the 
area. For this approach, nicknames in the L2 area MUST be unique but nicknames inside an L1 
area can be reused in other L1 areas that also use this approach. The use of the approach specified 
in this document in one L1 area does not prohibit the use of other approaches in other L1 areas in 
the same TRILL campus, for example the use of the unique nickname approach specified in 
[RFC8397]. The TRILL packet format is unchanged by this document, but data plane processing is 
changed at Border RBridges and efficient high volume data flow at Border RBridges might require 
forwarding hardware change. 


2. Acronyms and Terminology 


Area Border RBridge: A border RBridge between a Level 1 area and Level 2. 
Data Label: VLAN or Fine-Grained Label (FGL). 

DBRB: Designated Border RBridge. 

IS-IS: Intermediate System to Intermediate System [IS-IS]. 


Level: Similar to IS-IS, TRILL has Level 1 for intra-area and Level 2 for inter-area. Routing 
information is exchanged between Level 1 RBridges within the same Level 1 area, and Level 2 
RBridges can only form relationships and exchange information with other Level 2 RBridges. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Familiarity with [RFC6325] is assumed in this document. 
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3. Nickname Handling on Border RBridges 


This section provides an illustrative example and description of the border learning border 
RBridge nicknames. 


Area {2,20} Level 2 Area {3,30} 


| | | | | | 
| S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | 
| 27 | | 39 | | 44 | 
| ----RB20--- ----RB3@--- 


Figure 1: An Example Topology for TRILL Multilevel 


In Figure 1, RB2, RB20, RB3, and RB30 are area border TRILL switches (RBridges). Their nicknames 
are 2, 20, 3, and 30, respectively, and are used as TRILL switch identifiers in their areas [RFC6325]. 
Area border RBridges use the set of border nicknames to denote the L1 area that they are 
attached to. For example, RB2 and RB20 use nicknames {2,20} to denote the L1 area on the left. 


Asource S is attached to RB27 and a destination D is attached to RB44. RB27 has a nickname (say, 
27),and RB44 has a nickname (say, 44). (In fact, they could even have the same nickname, since 
the TRILL switch nickname will not be visible outside these Level 1 areas.) 


3.1. Actions on Unicast Packets 


Let's say that S transmits a frame to destination D and let's say that D's location has been learned 
by the relevant TRILL switches already. These relevant switches have learned the following: 


1) RB27 has learned that D is connected to nickname 3. 
2) RB3 has learned that D is attached to nickname 44. 


The following sequence of events will occur: 


1. S transmits an Ethernet frame with source MAC = S and destination MAC =D. 

2. RB27 encapsulates with a TRILL header with ingress RBridge = 27 and egress RBridge = 3 
producing a TRILL Data packet. 

3. RB2 and RB20 have announced in the Level 1 IS-IS area designated {2,20} that they are 
attached to the nicknames of all the border RBridges in the Level 2 area including RB3 and 
RB30. Therefore, IS-IS routes the packet to RB2 (or RB20, if RB20 is on the least-cost route from 
RB27 to RB3). 

4. RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch 
nickname with its own nickname, replacing 27 with 2. Within Level 2, the ingress RBridge 
field in the TRILL header will therefore be 2, and the egress RBridge field will be 3. (The egress 
nickname MAY be replaced with any area nickname selected from {3,30} such as 30. See 
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Section 4 for the detail of the selection method. Here, suppose the egress nickname remains 
3.) Also, RB2 learns that S is attached to nickname 27 in area {2,20} to accommodate return 
traffic. RB2 SHOULD synchronize with RB20 using the End Station Address Distribution 
Information (ESADI) protocol [RFC7357] that MAC = Sis attached to nickname 27. 

5. The packet is forwarded through Level 2, to RB3, which has advertised, in Level 2, its L2 
nickname as 3. 


6. RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with 
RB44's nickname (44) based on looking up D. (The ingress nickname MAY be replaced with 
any area nickname selected from {2,20}. See Section 4 for the detail of the selection method. 
Here, suppose the ingress nickname remains 2.) So, within the destination area, the ingress 
nickname will be 2 and the egress nickname will be 44. 


7. RB44, when decapsulating, learns that S is attached to nickname 2, which is one of the area 
nicknames of the ingress. 


3.2. Actions on Multi-destination Packets 


Distribution trees for flooding of multi-destination packets are calculated separately within each 
L1 area and in L2. When a multi-destination packet arrives at the border, it needs to be 
transitioned either from L1 to L2, or from L2 to L1. All border RBridges are eligible for Level 
transition. However, for each multi-destination packet, only one of them acts as the Designated 
Border RBridge (DBRB) to do the transition while other non-DBRBs MUST drop the received 
copies. By default, the border RBridge with the smallest nickname, considered as an unsigned 
integer, is elected DBRB. All border RBridges of an area MUST agree on the mechanism used to 
determine the DBRB locally. The use of an alternative is possible, but out of the scope of this 
document; one such mechanism is used in Section 4 for load balancing. 


As per [RFC6325], multi-destination packets can be classified into three types: unicast packets 
with unknown destination MAC addresses (unknown-unicast packets), multicast packets, and 
broadcast packets. Now suppose that D's location has not been learned by RB27 or the frame 
received by RB27 is recognized as broadcast or multicast. What will happen within a Level 1 area 
(as it would in TRILL today) is that RB27 will forward the packet as multi-destination, setting its M 
bit to 1 and choosing an L1 tree, which would flood the packet on that distribution tree (subject to 
potential pruning). 


When the copies of the multi-destination packet arrive at area border RBridges, non-DBRBs MUST 
drop the packet while the DBRB (say, RB2) needs to do the Level transition for the multi- 
destination packet. For an unknown-unicast packet, if the DBRB has learned the destination MAC 
address, it SHOULD convert the packet to unicast and set its M bit to 0. Otherwise, the multi- 
destination packet will continue to be flooded as a multicast packet on the distribution tree. The 
DBRB chooses the new distribution tree by replacing the egress nickname with the new tree root 
RBridge nickname from the area the packet is entering. The following sequence of events will 
occur: 


1. RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch 
nickname with its own nickname, replacing 27 with 2. RB2 also MUST replace the egress 
RBridge nickname with an L2 tree root RBridge nickname (say, 39). In order to accommodate 
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return traffic, RB2 records that S is attached to nickname 27 and SHOULD use the ESADI 
protocol [RFC7357] to synchronize this attachment information with other border RBridges 
(say, RB20) in the area. 


2. RB20 will receive the packet flooded on the L2 tree by RB2. It is important that RB20 does not 
transition this packet back to L1 as it does for a multicast packet normally received from 
another remote L1 area. RB20 should examine the ingress nickname of this packet. If this 
nickname is found to be a border RBridge nickname of the area {2,20}, RB2 must not forward 
the packet into this area. 


3. The multi-destination packet is flooded on the Level 2 tree to reach all border routers for all 
L1 areas including both RB3 and RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 
will drop the packet. 


4. RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with 
the root RBridge nickname of a distribution tree of L1 area {3,30} — say, 30. (Here, the ingress 
nickname MAY be replaced with a different area nickname selected from {2,20}, the set of 
border RBridges to the ingress area, as specified in Section 4.) Now suppose that RB27 has 
learned the location of D (attached to nickname 3), but RB3 does not know where D is 
because this information has fallen out of cache or RB3 has restarted or some other reason. 
In that case, RB3 must turn the packet into a multi-destination packet and then floods it ona 
distribution tree in the L1 area {3,30}. 

5. RB30 will receive the packet flooded on the L1 tree by RB3. It is important that RB30 does not 
transition this packet back to L2. RB30 should also examine the ingress nickname of this 
packet. If this nickname is found to be an L2 Border RBridge Nickname, RB30 must not 
transition the packet back to L2. 

6. The multicast listener RB44, when decapsulating the received packet, learns that S is attached 
to nickname 2, which is one of the area nicknames of the ingress. 


See also Appendix A. 


4. Per-Flow Load Balancing 


Area border RBridges perform ingress/egress nickname replacement when they transition TRILL 
Data packets between Level 1 and Level 2. The egress nickname will again be replaced when the 
packet transitions from Level 2 to Level 1. This nickname replacement enables the per-flow load 
balance, which is specified in the following subsections. The mechanism specified in Section 4.1 or 
that in Section 4.2 or both is necessary in general to load-balance traffic across L2 paths. 


4.1. L2-to-L1 Ingress Nickname Replacement 


When a TRILL Data packet from other L1 areas arrives at an area border RBridge, this RBridge 
MAY select one area nickname of the ingress area to replace the ingress nickname of the packet 
so that the returning TRILL Data packet can be forwarded to this selected nickname to help load- 
balance return unicast traffic over multiple paths. The selection is simply based on a 
pseudorandom algorithm as discussed in Section 5.3 of [RFC7357]. With the random ingress 
nickname replacement, the border RBridge actually achieves a per-flow load balance for 
returning traffic. 
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All area border RBridges for an L1 area MUST agree on the same pseudorandom algorithm. The 
source MAC address, ingress area nicknames, egress area nicknames, and the Data Label of the 
received TRILL Data packet are candidate factors of the input of this pseudorandom algorithm. 
Note that the value of the destination MAC address SHOULD be excluded from the input of this 
pseudorandom algorithm; otherwise, the egress RBridge could see one source MAC address flip- 
flopping among multiple ingress RBridges. 


4.2. L1-to-L2 Egress Nickname Replacement 


When a unicast TRILL Data packet originated from an L1 area arrives at an area border RBridge 
of that L1 area, that RBridge MAY select one area nickname of the egress area to replace the egress 
nickname of the packet. By default, it SHOULD choose the egress area border RBridge with the 
least cost route to reach or, if there are multiple equal cost egress area border RBridges, use the 
pseudorandom algorithm as defined in Section 5.3 of [RFC7357] to select one. The use of that 
algorithm MAY be extended to selection among some stable set of egress area border RBridges 
that include non-least-cost alternatives if it is desired to obtain more load spreading at the cost of 
sometimes using a non-least-cost Level 2 route to forward the TRILL Data packet to the egress 
area. 


5. Protocol Extensions for Discovery 


The following topology change scenarios will trigger the discovery processes as defined in 
Sections 5.1 and 5.2: 


e Anew node comes up or recovers from a previous failure. 

e Anode goes down. 

e A link or node fails and causes partition of an L1/L2 area. 

e A link or node whose failure has caused partitioning of an L1/L2 area is repaired. 


5.1. Discovery of Border RBridges in L1 


The following Level 1 Border RBridge APPsub-TLV will be included in E-L1FS FS-LSP fragment zero 
[RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV. Through listening for this APPsub-TLV, an 
area border RBridge discovers all other area border RBridges in this area. 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type = L1-BORDER-RBRIDGE | (2 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Length | (2 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Sender Nickname | (2 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+—+—+ 


Type: Level 1 Border RBridge (TRILL APPsub-TLV type 256) 


Length: 2 
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Sender Nickname: The nickname the originating IS will use as the L1 Border RBridge Nickname. 
This field is useful because the originating IS might own multiple nicknames. 


5.2. Discovery of Border RBridge Sets in L2 


The following APPsub-TLV will be included in an E-L2FS FS-LSP fragment zero [RFC7780] as an 
APPsub-TLV of the TRILL GENINFO-TLV. Through listening to this APPsub-TLV in L2, an area 
border RBridge discovers all groups of L1 border RBridges and each such group identifies an area. 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type = L1-BORDER-RB-GROUP | (2 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Length | (2 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
L1 Border RBridge Nickname 1 | (2 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Soe E re re 
L1 Border RBridge Nickname k | (2 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+— +—+— ++ 


Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type 257) 
Length: 2*k.Iflengthis not a multiple of 2, the APPsub-TLV is corrupt and MUST be ignored. 


L1 Border RBridge Nickname: The nickname that an area border RBridge uses as the L1 Border 
RBridge Nickname. The L1-BORDER-RB-GROUP TLV generated by an area border RBridge 
MUST include all L1 Border RBridge Nicknames of the area. It's RECOMMENDED that these k 
nicknames are ordered in ascending order according to the 2-octet nickname considered as 
an unsigned integer. 


When an L1 area is partitioned [RFC8243], border RBridges will re-discover each other in both L1 
and L2 through exchanging LSPs. In L2, the set of border RBridge nicknames for this splitting area 
will change. Border RBridges that detect such a change MUST flush the reachability information 
associated to any RBridge nickname from this changing set. 


6. One Border RBridge Connects Multiple Areas 


It's possible that one border RBridge (say, RB1) connects multiple L1 areas. RB1 SHOULD use a 
single area nickname for itself for all these areas to minimize nickname consumption and the 
number of nicknames being advertised in L2; however, sucha border RBridge might have to hold 
multiple nicknames -- for example, it might be the root of multiple L1 or multiple L2 distribution 
trees. 


Nicknames used within one of these L1 areas can be reused within other areas. It's important that 
packets destined to those duplicated nicknames are sent to the right area. Since these areas are 
connected to form a layer 2 network, duplicated {MAC, Data Label} across these areas SHOULD 
NOT occur (see Section 4.2.6 of [RFC6325] for tie breaking rules). Now suppose a TRILL Data packet 
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arrives at the area border nickname of RB1. Fora unicast packet, RB1 can look up the {MAC, Data 
Label} entry in its MAC table to identify the right destination area (i.e., the outgoing interface) 
and the egress RBridge's nickname. For a multicast packet for each attached L1 area: either RB1 is 
not the DBRB and RB1 will not transition the packet, or RB1 is the DBRB. If RB1 is the DBRB, RB1 
follows the following rules: 


e If this packet originated from an area out of the connected areas, RB1 replicates this packet 
and floods it on the proper Level 1 trees of all the areas in which it acts as the DBRB. 


e If the packet originated from one of the connected areas, RB1 replicates the packet it receives 
from the Level 1 tree and floods it on other proper Level 1 trees of all the areas in which it acts 
as the DBRB except the originating area (i.e., the area connected to the incoming interface). 
RB1 might also receive the replication of the packet from the Level 2 tree. This replication 
MUST be dropped by RB1. It recognizes such packets by their ingress nickname being the 
nickname of one of the border RBridges of an L1 area for which the receiving border RBridge 
is DBRB. 


7. E-L1FS/E-L2FS Backwards Compatibility 


All Level 2 RBridges MUST support E-L2FS [RFC7356] [RFC7780]. The Extended TLVs defined in 
Section 5 are to be used in Extended Level 1/2 Flooding Scope (E-L1FS/E-L2FS) Protocol Data Units 
(PDUs). Area border RBridges MUST support both E-L1FS and E-L2FS. RBridges that do not support 
both E-L1FS or E-L2FS cannot serve as area border RBridges but they can appear in an L1 area 
acting as non-area-border RBridges. 


8. Manageability Considerations 


If an L1 Border RBridge Nickname is configured at an RBridge and that RBridge has both L1 and 
L2 adjacencies, the multilevel feature as specified in this document is turned on for that RBridge 
and normally uses an L2 nickname in both L1 and L2 although, as provided below, such an 
RBridge may have to fall back to multilevel unique nickname behavior [RFC8397], in which case it 
uses this L1 nickname. In contrast, unique nickname multilevel as specified in [RFC8397] is 
enabled by the presence of L1 and L2 adjacencies without an L1 Border RBridge Nickname being 
configured. RBridges supporting only unique nickname multilevel do not support the 
configuration of an L2 Border RBridge Nickname. RBridges supporting only the single-level TRILL 
base protocol specified in [RFC6325] do not support L2 adjacencies. 


RBridges that support and are configured to use single nickname multilevel as specified in this 
document MUST support unique nickname multilevel [RFC8397]. If there are multiple border 
RBridges between an L1 area and L2, and one or more of them only support or are only 
configured for unique nickname multilevel [RFC8397], any of these border RBridges that are 
configured to use single nickname multilevel MUST fall back to behaving as a unique nickname 
border RBridge for that L1 area. Because overlapping sets of RBridges may be the border RBridges 
for different L1 areas, an RBridge supporting single nickname MUST be able to simultaneously 
support single nickname for some of its L1 areas and unique nickname for others. For example, 
RB1 and RB2 might be border RBridges for L1 area A1 using single nickname while RB2 and RB3 
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are border RBridges for area A2. If RB3 only supports unique nicknames, then RB2 must fall back 
to unique nickname for area A2 but continue to support single nickname for area A1. Operators 
SHOULD be notified when this fallback occurs. The presence of border RBridges using unique 
nickname multilevel can be detected because they advertise in L1 the blocks of nicknames 
available within that L1 area. 


In both the unique nickname approach specified in [RFC8397] and the single nickname 
aggregated approach specified in this document, an RBridge that has L1 and L2 adjacencies uses 
the same nickname in L1 and L2. If an RBridge is configured with an L1 Border RBridge Nickname 
for any a Level 1 area, it uses this nickname across the Level 2 area. This L1 Border RBridge 
Nickname cannot be used in any other Level 1 area except other Level 1 areas for which the same 
RBridge is a border RBridge with this L1 Border RBridge Nickname configured. 


In addition to the manageability considerations specified above, the manageability 
specifications in [RFC6325] still apply. 


Border RBridges replace ingress and/or egress nickname when a TRILL Data packet traverses a 
TRILL L2 area. A TRILL Operations, Administration, and Maintenance (OAM) message will be 
forwarded through the multilevel single nickname TRILL campus using a MAC address belonging 
to the destination RBridge [RFC7455]. 


9. Security Considerations 
For general TRILL Security Considerations, see [RFC6325]. 


The newly defined TRILL APPsub-TLVs in Section 5 are transported in IS-IS PDUs whose 
authenticity can be enforced using regular IS-IS security mechanism [IS-IS] [RFC5310]. Malicious 
devices may also fake the APPsub-TLVs to attract TRILL Data packets, interfere with multilevel 
TRILL operation, induce excessive state in TRILL switches (or in any bridges that may be part of 
the TRILL campus), etc. For this reason, RBridges SHOULD be configured to use the IS-IS 
Authentication TLV (10) in their IS-IS PDUs so that IS-IS security [RFC5310] can be used to 
authenticate those PDUs and discard them if they are forged. 


Using a variation of aggregated nicknames, and the resulting possible duplication of nicknames 
between areas, increases the possibility of a TRILL Data packet being delivered to the wrong 
egress RBridge if areas are unexpectedly merged as compared witha scheme where all 
nicknames in the TRILL campus are, except as a transient condition, unique such as the scheme 
in [RFC8397]. However, in many cases, the data would be discarded at that egress RBridge because 
it would not matcha known end station Data Label / MAC address. 


10. IANA Considerations 


IANA has allocated two new types under the TRILL GENINFO TLV [RFC7357] from the range 
allocated by Standards Action [RFC8126] for the TRILL APPsub-TLVs defined in Section 5. The 
following entries have been added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 
Application Identifier 1" registry on the TRILL Parameters IANA web page. 
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Appendix A. Level Transition Clarification 


It's possible that an L1 RBridge is only reachable from a non-DBRB border RBridge. If this non- 
DBRB RBridge refrains from Level transition, the question is, how can a multicast packet reach 
this L1 RBridge? The answer is, it will be reached after the DBRB performs the Level transition and 
floods the packet using an L1 distribution tree. 


Take the following figure as an example. RB77 is reachable from the border RBridge RB30 while 
RB3 is the DBRB. RB3 transitions the multicast packet into L1 and floods the packet on the 
distribution tree rooted from RB3. This packet is finally flooded to RB77 via RB30. 


Area{3, 30} 

GP a iets + (root) RB3 o 
| \ 

-RB3 | | o RB30 
a | / 
-RB30-RB77 | RB77 o 

+-------------- + 

Example Topology L1 Tree 


In the above example, the multicast packet is forwarded along a non-optimal path. A possible 
improvement is to have RB3 configured not to belong to this area. In this way, RB30 will surely act 
as the DBRB to do the Level transition. 
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